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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 


Abstract 


This memo describes the use of the Advanced Encryption Standard (AES) 
in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security 
Payload (ESP) mechanism to provide confidentiality and data origin 
authentication. This method can be efficiently implemented in 
hardware for speeds of 10 gigabits per second and above, and is also 
well-suited to software implementations. 
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1. Introduction 


This document describes the use of AES in GCM mode (AES-GCM) as an 
IPsec ESP mechanism for confidentiality and data origin 
authentication. We refer to this method as AES-GCM-ESP. This 
mechanism is not only efficient and secure, but it also enables 
high-speed implementations in hardware. Thus, AES-GCM-ESP allows 
IPsec connections that can make effective use of emerging 10-gigabit 
and 40-gigabit network devices. 


Counter mode (CTR) has emerged as the preferred encryption method for 
high-speed implementations. Unlike conventional encryption modes 
such as Cipher Block Chaining (CBC) and Cipher Block Chaining Message 
Authentication Code (CBC-MAC), CTR can be efficiently implemented at 
high data rates because it can be pipelined. The ESP CTR protocol 
describes how this mode can be used with IPsec ESP [RFC3686]. 


Unfortunately, CTR provides no data origin authentication, and thus 
the ESP CTR standard requires the use of a data origin authentication 
algorithm in conjunction with CTR. This requirement is problematic, 
because none of the standard data origin authentication algorithms 
can be efficiently implemented for high data rates. GCM solves this 
problem, because under the hood, it combines CTR mode with a secure, 
parallelizable, and efficient authentication mechanism. 


This document does not cover implementation details of GCM. Those 
details can be found in [GCM], along with test vectors. 


1.1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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AES-GCM 


GCM is a block cipher mode of operation providing both 
confidentiality and data origin authentication. The GCM 
authenticated encryption operation has four inputs: a secret key, an 
initialization vector (IV), a plaintext, and an input for additional 
authenticated data (AAD). It has two outputs, a ciphertext whose 
length is identical to the plaintext, and an authentication tag. In 
the following, we describe how the IV, plaintext, and AAD are formed 
from the ESP fields, and how the ESP packet is formed from the 
ciphertext and authentication tag. 


ESP also defines an IV. For clarity, we refer to the AES-GCM IV as a 
nonce in the context of AES-GCM-ESP. The same nonce and key 
combination MUST NOT be used more than once. 


Because reusing an nonce/key combination destroys the security 
guarantees of AES-GCM mode, it can be difficult to use this mode 
securely when using statically configured keys. For safety's sake, 
implementations MUST use an automated key management system, such as 
the Internet Key Exchange (IKE) [RFC2409], to ensure that this 
requirement is met. 


ESP Payload Data 


The ESP Payload Data is comprised of an eight-octet initialization 
vector (IV), followed by the ciphertext. The payload field, as 
defined in [RFC2406], is structured as shown in Figure 1, along with 
the ICV associated with the payload. 


0 1 2 3 
012345678°9012345678°9012345678901 
+-4+-+4+-4+-4-4+-4+-4+-4-4+-4-4+-4+-4+-4-4-4-4-4-4-4+-4-4-4+-4+-4+-4-4+-4+-4-4-4-4+ 

Initialization Vector 
(8 octets) 
+-4+-+4+-4+-4-4+-4+-4-4+-4+-4-4-4+-4+-4+-4-4-4+-4-4-4+-4-4-4+-4-4-4-4-4+-4-4-4+-4+ 
| | 


Ciphertext (variable) a 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: ESP Payload Encrypted with AES-GCM. 
l Initialization Vector (IV) 
The AES-GCM-ESP IV field MUST be eight octets. For a given key, the 


IV MUST NOT repeat. The most natural way to implement this is with a 
counter, but anything that guarantees uniqueness can be used, such as 
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a linear feedback shift register (LFSR). Note that the encrypter can 
use any IV generation method that meets the uniqueness requirement, 
without coordinating with the decrypter. 


3.2. Ciphertext 


The plaintext input to AES-GCM is formed by concatenating the 
plaintext data described by the Next Header field with the Padding, 
the Pad Length, and the Next Header field. The Ciphertext field 
consists of the ciphertext output from the AES-GCM algorithm. The 
length of the ciphertext is identical to that of the plaintext. 


Implementations that do not seek to hide the length of the plaintext 
SHOULD use the minimum amount of padding required, which will be less 
than four octets. 


4. Nonce Format 


The nonce passed to the GCM-AES encryption algorithm has the 
following layout: 


0 1 2 3 
QUI. 2: 3 44 7-8 89. 0b 2. 344506. 8.494 0.2: 38.415 6:4 :8:9x0:a1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Salt | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Initialization Vector | 


t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4+-4-4-4t-4+-4-4+-4+-4-4-4+-4-4-4+-4-4-4 
Figure 2: Nonce Format 
The components of the nonce are as follows: 


Salt 
The salt field is a four-octet value that is assigned at the 
beginning of the security association, and then remains constant 
for the life of the security association. The salt SHOULD be 
unpredictable (i.e., chosen at random) before it is selected, but 
need not be secret. We describe how to set the salt fora 
Security Association established via the Internet Key Exchange in 
Section 8.1. 


Initialization Vector 
The IV field is described in Section 3.1. 
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5. AAD Construction 


The authentication of data integrity and data origin for the SPI and 
(Extended) Sequence Number fields is provided without encryption. 
This is done by including those fields in the AES-GCM Additional 
Authenticated Data (AAD) field. Two formats of the AAD are defined: 
one for 32-bit sequence numbers, and one for 64-bit extended sequence 


numbers. The format with 32-bit sequence numbers is shown in Figure 
3, and the format with 64-bit extended sequence numbers is shown in 
Figure 4. 

0 1 2 3 


Oo 2-349 S P 8:9-0. 1234 9 Ge e a a 2S: Ao 46) 7 28 9 Ook: 
FOTO HAT ATA HIT HIT HI H 
| SPI 
$otatatatatatititotititotitatatatatitititititotitatatatatatototet 
| 32-bit Sequence Number 
$ototatatatatititotititotitatatatatitititititititatatatatitototet 


Figure 3: AAD Format with 32-bit Sequence Number 


0 1 2 3 
OPT 2. FA O56 89 S08 W223 As S60 SE Bo. OL 2 3.45 6:4 82°90 
cool ooo poo popo popo po oo oo poo ooo ooo popo pop pan pa 
| SPI | 
cool lo ooo popo popo popo ooo ooo ooo ooo ooo pop pa pa 

| 64-bit Extended Sequence Number 


foto toro roro ooo oo lo oo lo po popo poo popo lo po popo popo pa papa po 
Figure 4: AAD Format with 64-bit Extended Sequence Number 
6. Integrity Check Value (ICV) 


The ICV consists solely of the AES-GCM Authentication Tag. 
Implementations MUST support a full-length 16-octet ICV, and MAY 
support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. 
Although ESP does not require that an ICV be present, AES-GCM-ESP 
intentionally does not allow a zero-length ICV. This is because GCM 
provides no integrity protection whatsoever when used with a zero- 
length Authentication Tag. 
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7. Packet Expansion 


The IV adds an additional eight octets to the packet, 
or 16 octets. 
other than the 10-13 octets taken up by the ESP 
Pad Length, 


adds an additional 8, 12, 
of packet expansion, 
SPI, Sequence Number, Padding, 


the minimal amount of padding is 
8. IKE Conventions 


This section 
material and salt values, 
Internet Key Exchange (IKE) 
attributes needed to negotiate a 
ESP are also defined. 


8.1. 


IKE makes use of a pseudo-random 
material. 


arbitrary size, called KEYMAT. 


ESP June 2005 


and the ICV 
These are the only sources 


and Next Header fields (if 


used). 


describes the conventions used to generate keying 
for use with AES-GCM-ESP, 
[RFC2409] protocol. 


using the 
The identifiers and 
security association using AES-GCM- 


Keying Material and Salt Values 


function (PRF) to derive keying 


The PRF is used iteratively to derive keying material of 
Keying material is extracted from the 


output string without regard to boundaries. 


The size of the KEYMAT for the AES-GCM-ESP MUST be four octets longer 


than is needed for the associated AES key. 


used as follows: 


AES-GCM-ESP with a 128 bit key 
The KEYMAT requested for each 
16 octets are the 128-bit AES 
are used as the salt value in 


AES-GCM-ESP with a 192 bit key 
The KEYMAT requested for each 
24 octets are the 192-bit AES 
are used as the salt value in 


AES-GCM-ESP with a 256 bit key 
The KEYMAT requested for each 
32 octets are the 256-bit AES 
are used as the salt value in 


Phase 1 Identifier 


The keying material is 


AES-GCM key is 20 octets. The first 
key, and the remaining four octets 
the nonce. 


AES-GCM key is 28 octets. The first 
key, and the remaining four octets 
the nonce. 


AES GCM key is 36 octets. The first 
key, and the remaining four octets 
the nonce. 


This document does not specify the conventions for using AES-GCM for 


IKE Phase 1 negotiations. 


separate specification is needed, 


Identifier needs to be assigned. 


Viega & McGrew 


For AES-GCM to be used in this manner, 


Standards Track 


a 
and an Encryption Algorithm 
Implementations SHOULD use an IKE 
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Phase 1 cipher that is at least as strong as AES-GCM. The use of AES 
CBC [RFC3602] with the same key size used by AES-GCM-ESP is 
RECOMMENDED. 


8.3. Phase 2 Identifier 


For IKE Phase 2 negotiations, IANA has assigned three ESP Transform 
Identifiers for AES-GCM with an eight-byte explicit IV: 


18 for AES-GCM with an 8 octet ICV; 
19 for AES-GCM with a 12 octet ICV; and 
20 for AES-GCM with a 16 octet ICV. 


8.4. Key Length Attribute 


Because the AES supports three key lengths, the Key Length attribute 
MUST be specified in the IKE Phase 2 exchange [RFC2407]. The Key 
Length attribute MUST have a value of 128, 192, or 256. 


9. Test Vectors 


Appendix B of [GCM] provides test vectors that will assist 
implementers with AES-GCM mode. 


10. Security Considerations 


GCM is provably secure against adversaries that can adaptively choose 
plaintexts, ciphertexts, ICVs, and the AAD field, under standard 
cryptographic assumptions (roughly, that the output of the underlying 
cipher, under a randomly chosen key, is indistinguishable from a 
randomly selected output). Essentially, this means that, if used 
within its intended parameters, a break of GCM implies a break of the 
underlying block cipher. The proof of security for GCM is available 
in [GCM]. 


The most important security consideration is that the IV never repeat 
for a given key. In part, this is handled by disallowing the use of 
AES-GCM when using statically configured keys, as discussed in 
Section 2. 


When IKE is used to establish fresh keys between two peer entities, 
separate keys are established for the two traffic flows. Ifa 
different mechanism is used to establish fresh keys (one that 
establishes only a single key to encrypt packets), then there is a 
high probability that the peers will select the same IV values for 
some packets. Thus, to avoid counter block collisions, ESP 


Viega & McGrew Standards Track [Page 7] 


RFC 4106 GCM ESP June 2005 


lil. 


AZA 


implementations that permit use of the same key for encrypting and 
decrypting packets with the same peer MUST ensure that the two peers 
assign different salt values to the security association (SA). 


The other consideration is that, as with any encryption mode, the 
security of all data protected under a given security association 
decreases slightly with each message. 


To protect against this problem, implementations MUST generate a 
fresh key before encrypting 2564 blocks of data with a given key. 
Note that it is impossible to reach this limit when using 32-bit 
Sequence Numbers. 


Note that, for each message, GCM calls the block cipher once for each 
full I6-octet block in the payload, once for any remaining octets in 
the payload, and one additional time for computing the ICV. 


Clearly, smaller ICV values are more likely to be subject to forgery 
attacks. Implementations SHOULD use as large a size as reasonable. 


Design Rationale 


This specification was designed to be as similar to the AES-CCM ESP 
[CCM-ESP] and AES-CTR ESP [RFC3686] mechanisms as reasonable, while 
promoting simple, efficient implementations in both hardware and 
software. We re-use the design and implementation experience from 
those standards. 


The major difference with CCM is that the CCM ESP mechanism requires 
an ll-octet nonce, whereas the GCM ESP mechanism requires using a 
12-octet nonce. GCM is specially optimized to handle the 12-octet 
nonce case efficiently. Nonces of other lengths would cause 
unnecessary, additional complexity and delays, particularly in 
hardware implementations. The additional octet of nonce is used to 
increase the size of the salt. 


IANA Considerations 


IANA has assigned three ESP Transform Identifiers for AES-GCM with an 
eight-byte explicit IV: 


18 for AES-GCM with an 8 octet ICV; 
19 for AES-GCM with a 12 octet ICV; and 
20 for AES-GCM with a 16 octet ICV. 
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